Due to the limitation of physical conditions, in a mobile communication system, a wireless link has a lower transmission rate and a higher bit error rate than a wired link. In order to effectively use the limited wireless channel bandwidth resources, the RObust Header Compress (hereinafter referred to as the ROHC) technology is introduced. The core of the ROHC is to use information redundancy between packets of a traffic flow to transparently compress and decompress the information in headers of packets between nodes which are connected directly. The ROHC technology is described in the Internet Engineering Task Force (IETF) RFC3095 document.
The Least Significant Bits (LSB) algorithm is an important algorithm in the ROHC technology, which is mainly used to compress the Master Sequence Number (MSN) information. The LSB compression algorithm performs LSB compression on a value A which is to be compressed and occupies k1 bits by using one reference value V_ref and specifying a P value, and subsequently obtains a compressed value B which occupies less k2 bits and is associated with the V_ref. Through the LSB compression, bits with no change are deleted, and the B value represents the least significant bits which change from the value V_ref to the value A (i.e., B=low k2 bits of A). The process of recovering the compressed value using the LSB decompression is contrary to the above process.
ROHC is released in 2001, and because the reorder submission situation did not exist in the link at that time, the ROHC is defined to be applied to an order submission link at the beginning of the design. As time goes on, the ROHC has been widely used in more and more wireless devices, and compared with other compression algorithms, “the ROHC being not capable of working effectively on a reorder submission link” becomes a weakness of the ROHC.
On the order submission link, compressed packets which are transmitted from a source end ROHC compressor can be submitted to a ROHC decompressor in order at the destination end after being transmitted over a link. For example, if the compressor transmits five data packets, i.e., 1, 2, 3, 4, 5 in order, the order of receiving these data packets by the decompressor is also 1, 2, 3, 4, 5, and such a process is desired by the ROHC, and is also a condition for a normal work; while in a reorder submission link, the order of the data packets may be influenced by an underlying link, which makes the order of the data packets received by the ROHC decompressor at the destination end is different from the order of transmission by the ROHC compressor at the source end, thus finally resulting in that the decompressor can not decompress the data packets normally. For example, if the compressor transmits five data packets, i.e., 1, 2, 3, 4, 5 in order, in the process of link transmission, as a false retransmission occurs with respect to data packet 3 on an underlying link, which makes the order of receiving these data packets by the decompressor be 1, 2, 4, 5, 3, wherein, data packet 3 is referred to as a late sequence packet, and data packets 4 and 5 are referred to as early sequence packets, and the number of the early sequence packets is referred to as a reorder depth, which is 2 in this example. Such a process is not desired by the ROHC, and abnormal processing for the early sequence packets may cause a failure of the decompression of the late sequence packets, thus resulting in state transition of the decompressor and influencing the compression efficiency; and abnormal processing for the late sequence packets may cause asynchronization of contexts of the compressor and the decompressor, and influence the robustness. As the reorder process of the data packets in the link can not be anticipated and it may occur in any stage of the ROHC process, when this situation comes forth, the method for processing the data packet 3, 4 and 5 will influence the efficiency and robustness of the whole ROHC directly.
In order to improve such a situation, the RFC4224 document was released by IETE in 2006, and in this document, a plurality of methods which can enhance the compression efficiency and robustness of a reorder submission link in terms of how to be compatible with the reorder submission link by the ROHC are provided. However, in all schemes proposed in the RFC4224, as there is no feedback related to the reorder depth between the compressor and the decompressor, the compressor can not exactly obtain a maximum reorder depth of the current link, which finally results in that the compressor can only unilaterally perform estimation when selecting a suitable LSB encoded P value, and such an estimation can not really avoid the decompression problem due to the reorder in some cases.
As the second version of the ROHC, the RFC 5225 uses a number of ideas in the RFC 4224, and introduces a concept of reorder_ratio when calculating the LSB P value, i.e., dynamically adjusting the LSB P value as 2^(k−2)*reorder_ratio (as shown in FIG. 1, wherein, a value of reorder_ratio can only be one of 0, 1, 2 and 3), so that the ROHCv2 can support the reorder submission to some extent.
However, in the specific implementation, as there is no communication between the compressor and the decompressor against the reorder situation in the current link, one can not accurately select the value. For example, when the compressor solves the reorder submission problem by adjusting the P value in the LSB algorithm, the value of the P is selected as 2^k/3 by way of example in the RFC 4224 document, but the document does not describe whether to select2^k/4, 2^k/2 or 2^k*¾ in different links. As for the whole ROHC, the compression efficiency and robustness when selecting different P values is totally different, for the RFC5225 per se, it does not introduce a new reorder processing method, and thus it can not solve the problem exist in the RFC4224 as well.